Would a SELECT query within the same, isolated transaction give us the number of rows matched but not updated?

@adamziel I think so, yes, but in SQLite, that seems to equal the number from SELECT CHANGES() and the row cound from PDO APIs.

We'd need to add a condition such as SELECT * FROM target_table WHERE ($original_update_conditions) to get the number of matching rows and a condition such as SELECT * FROM target_table WHERE ($original_update_conditions) AND NOT (field1 = :updated_value1 OR field2 = :updated_value2) to get the number of changed rows. It is a fair limitation to have, but it also seems like a tractible problem.

@adamziel Ah, right, I see what you mean now. This approach could likely be applied directly to the UPDATE by rewriting it to directly exclude the rows where the existing values are equal to the new ones:

UPDATE ... SET col1 = val1, col2 = val2 WHERE ... AND (col1 != val1 OR col2 != val2)

Then the number of affected rows should be correct, but maybe the caveat is that in edge cases like with triggers, this could get tricky. That said, we don't support MySQL triggers and can probably never fully support them.

Really good idea to fold this directly into the update query.

It's fine to disregard triggers here. They're not a big priority at this point. We could leave a comment to document what needs to be done if we ever get to support triggers.

@adamziel In that case, I think I can close this PR and create an issue to implement this into the UPDATE query instead.